The IP Multimedia Subsystem (IMS) is a Next Generation Networking (NGN) architecture for telecom operators, standardised by the Third Generation Partnership Project (3GPP), which can provide multimedia services to mobile and fixed terminals. IMS uses SIP (Session Initiation Protocol) based signaling and Internet Protocol (IP) connectivity.
A number of CSCF (Call Session Control Function) entities are used to establish a session within the IMS network and process SIP signaling packets. The CSCF entities are the Proxy-CSCF (P-CSCF), Interrogating-CSCF (I-CSCF) and Serving-CSCF (S-CSCF). FIG. 1 shows part of an IMS network which includes the S-CSCF. The S-CSCF is responsible for handling registration processes, making routing decisions and maintaining session states.
Application servers (AS) within an IMS network can host and execute applications which provide services. An Application Server interfaces with the S-CSCF via an IMS Service Control (ISC) interface 24 which uses SIP signaling. Services can include call related services such as Call waiting, Call holding, Call forwarding, Call transfer, Call blocking services. Applications can also provide services such as notifying a user of particular information, such as stock prices or football results. Applications can be provided by the operator of the IMS network, with the application being hosted and executed by a SIP Application Server within the IMS network.
Alternatively, an application can be provided by a third party service provider external to the IMS network, as shown in FIG. 1. An Application Server 30 within the IMS network, called an Open Service Architecture Service Capability Server (OSA SCS), can provide IMS network resources to implement the external service. The S-CSCF communicates with the OSA-SCS over an IMS Service Control (ISM), SIP-based, signaling interface 24. An OSA gateway 14 acts as an intermediary between the OSA SCS 30 and an Application 42 in the IT environment 40. An Application can interface directly with the OSA Gateway 14 via an OSA Application Programming Interface (OSA API), which typically uses Parlay over CORBA. Application 41 interfaces with OSA Gateway 14 in this manner. For Applications which use XML, a Parlay-X interface is used and a Parlay-X gateway 16 is required. Application 42 uses a Parlay-X interface to communicate with the Parlay-X gateway 16. The Parlay-X gateway uses a Parlay interface to communicate with the OSA gateway 14. IT-based applications or web-based services typically exchange data in an XML format, and so the arrangement of gateways 14, 16 is usually required. It can be seen that, with the current architecture, two gateway elements are required whenever an application 42 which uses an XML messaging format is connected to the IMS network. This considerably increases the complexity of implementing services provided by third parties.
An Application Server 30 may be dedicated to a single service, or it may be shared by several services (as shown by ‘Application A’ 41 and ‘Application B’ 42 in FIG. 1). Multiple Application Servers 30 can participate in a single session. For example, a particular call between two users may involve a call transfer service and a music-on-hold service.
Currently, Application Server billing triggers are all related to SIP and ISUP protocols and are resident at the CSCF (Call Session Control Function) plane. A disadvantage with this approach is that it is not possible to properly track the IMS network resources used by an IT-based service external to the IMS network. This problem can arise, for example, where an Application Server is used by multiple third parties. While conventional mechanisms can monitor use of the Application Server resources as a whole, they cannot monitor use by particular external applications.
Accordingly, the present invention seeks to reduce, or overcome, this problem.